feat(ogc): add the water well field operations internal layer - #914

Adds water_well_field_operations, an OGC API - Features collection on
/ogcapi-internal only: one feature per water well carrying what a field crew
needs to plan and execute a visit. Every other well layer answers a scientific
question -- water level, chemistry, trend. This one answers an operational one:
may we go to this well, what are we allowed to do when we get there, and is it
overdue?

86 columns: identity and location (including latitude and longitude in decimal
degrees and how the elevation was obtained), construction detail, the current
measuring point, all five status types, the three standing landowner
permissions, monitoring frequency and group membership, manual water-level and
chemistry-sampling statistics, field-visit history, the installed logger and
its continuous record, landowner contacts, and access and directions notes.

Two relations rather than one (migration e1f2a3b4c5d6):

  ogc_internal_water_well_field_operations_stats  materialized, nightly refresh
      Aggregates over observation and transducer_observation.

  ogc_internal_water_well_field_operations        plain view, served by pygeoapi
      Live join of thing, location, status_history, permission_history,
      measuring_point_history, monitoring_frequency_history, deployment,
      sensor, contact and notes, LEFT JOINed to the stats matview.

The split is not tidiness. Staleness is dangerous on exactly the columns that
are cheap to read: a revoked sampling permission that still reads true until
the next nightly refresh sends a crew onto land they are no longer welcome on.
The current-record rule is also written against CURRENT_DATE, which inside a
materialized view would freeze at refresh time.

Three decisions worth review:

* Internal-only with no public twin. The layer publishes landowner and operator
  contact details -- name, organization, role, phone, email -- alongside
  staff-written access notes. ogc_water_well_field_operations does not exist
  and must never be created. Every credential the internal mount accepts now
  reaches personal information, the static desktop-GIS keys included; notices
  added to CLAUDE.md and docs/internal-ogc-desktop-gis.md.

* The three permission columns are three-valued. NULL means no permission is on
  record, which is not a refusal -- it means nobody has asked the landowner
  yet. Collapsing it to false would tell a crew a well is off limits when the
  truth is unknown.

* History reads honour end_date, unlike ogc_actively_monitored_wells, which
  takes the greatest start_date and lets a status closed in 2019 read as
  current. Written up in docs/ogc_conventions.md.

Requested as amp_field_well_operations and renamed before merge per the
pre-merge check in docs/ogc_conventions.md: amp is an unexpanded abbreviation
whose expansion is recorded nowhere in this codebase, AMP labels the layer's
audience rather than filtering its rows (the row set is every water well), and
Group B analytic layers prefer a water_well_ prefix. The AMP crews stay named
in the collection description.

Multi-valued columns are comma-joined text rather than arrays: this layer is
pulled into ArcGIS Pro and QGIS and exported to File Geodatabase and GeoPackage
for offline field use, and neither format has a list type.

Depth to water uses the (value - COALESCE(measuring_point_height, 0))
convention shared with ogc_water_well_summary, ogc_latest_depth_to_water_wells
and ogc_well_water_column, and elevation_method reuses that summary's
provenance lookup verbatim, so the layers cannot disagree.

Twelve supporting indexes come with the migration; none of the foreign keys
these lookups traverse was indexed.

Design rationale in docs/water-well-field-operations-layer.md, column-by-column
sources in docs/water-well-field-operations-columns.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/features/ogc-cleanup-sprint1.feature's "Internal database
relations are separate from public relations" scenario asserts that
every ogc_internal_ relation in the schema has a distinct ogc_ public
counterpart. That held for every internal-only collection so far
(locations, avg_tds_wells, latest_depth_to_water_wells): each is
hidden from the public collections catalog, but both relations still
exist in the database.

water_well_field_operations breaks that pattern on purpose.
ogc_water_well_field_operations does not exist at all, by design (see
docs/water-well-field-operations-layer.md section 3), since the
layer publishes landowner contact details and staff-written notes.
The check had no way to know that was intentional, so it failed CI on
this PR.

Added an explicit exception set for the two relations this layer
introduces, rather than loosening the assertion generally. The check
should still fail if some future ogc_internal_ relation is missing
its public twin by accident.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>